Communication networks can be subdivided into core networks and access networks, the latter providing access to user equipment, for example a wireless access for mobile user equipment to a radio access network. Core networks interconnect access networks and optionally further networks, e.g. the Internet. In the UMTS architecture, an access network can be controlled by an RNC (radio network controller) which is connected to the core network and provides access to the core network, i.e. serves as access node. In 3GPP (3rd Generation Partnership Project) Technical Specification 3G TS 25.415 V3.2.0, the interface between the access node and a node in the core network is denoted as Iu interface. Over the Iu interface, connections can be established according to the Iu user plane protocol.
RFCIs (radio access bearer subflow combination indicators) are indicators to sets of parameters which are generated by an RNC in radio access bearer (RAB) assignments. They indicate which service data unit formats are valid, for example for use in speech frames or in rate control requests received from the core network, and how they are formatted. RFCIs determine the codec mode, especially allowed rates. When a transcoder is inserted into a connection, it receives data frames, e.g. Iu frames, and relates the assigned RFCI to a codec mode in order to decode the frames. In the same way, it must indicate the RFCI when it sends an encoded frame.
The Iu interface as specified in 3GPP Technical Specification 3G TS 25.415 terminates in a core network node, for example in an MSC or in a media gateway controlled by an MSC server, according to the architecture of the core network. In a core network node, the content of data sent over a connection can be changed. Especially, the payload or speech coding can be adapted, for example due to the intervention of supplementary services like DTMF (Dual Tone Multifrequency) tone insertion, supplementary services tone insertion, messages or conference connections of user equipment.
For connections between nodes within the core network, different protocols are possible. Beside the Iu user plane protocol, 1.366.2 is a protocol defined by the ITU (International Telecommunication Union) as service specific convergence sublayer (SSCS) used on AAL2 (Asynchronous Transfer Mode Adaptation Layer Type 2) for carrying service specific payloads. Especially, it is the framing protocol proposed to be used for carrying compressed voice. This requires the core network node to terminate the Iu interface and to establish an AAL2 connection with the required SSCS for the selected speech coding type. A further framing protocol is RTP (Real Time Protocol) which can be carried on an IP transport layer in the core network for transmission of compressed voice of a specified encoding.
A problem with both RTP and 1.366.2 is that they are application dependent and transport layer dependant. If the coding type changes during a connection, a new AAL2 connection or modification must be made with the new SSCS profile. For an IP network, a new RTP profile must be used. This requires unnecessary overhead to carry the profiles with the payload. A further problem with SSCS or RTP is that both are service specific. The protocols require modifications in standardization and implementation for every new service.
In contrast to this, the Iu user plane protocol is defined service independent. An Iu interface can be connected between two access nodes, e.g. by using BICC (Bearer Independent Call Control) messages to pass the bearer address used in a first access node from a server, e.g. an MSC, controlling it to the server controlling the other access node. In this case, it is disadvantageous that there is no control of the user plane. For example, when a handover is necessary or a supplementary service invocation occurs, the Iu connection has to be cancelled and a new Iu connection must be established which is very inefficient and would degrade the service level. However, for most of the time in a connection, supplementary services or other functions within the connection path are not necessary and hence a virtually direct and transparent connection between access nodes or an access node and a transcoder is advantageous.
The other described framing protocols do not carry the Iu user plane parameters. Transcoders are necessary to terminate the Iu connection and need to receive the parameters sent by the Iu user plane initialization procedure (RFCIs). If another of the above-described framing protocols is used in the core network, the Iu user plane protocol is terminated at the first core network node in the connection, e.g. a media gateway. The payload content is then mapped to the other framing protocol.
Furthermore, the RFCI initialization must be carried by the other framing protocol and possibly mapped to the actual mode as the framing is codec type specific. At the final core network node in the connection, a transcoder to terminate the Iu connection to the access node must then be initialized and the payload content must be mapped back to the Iu user plane protocol which requires sufficient processing capacity.
It is also conceivable that parameter sets like RFCIs are transferred from access nodes by out-band procedures, i.e. the core network nodes are provided with parameter sets by a vertical control protocol from servers controlling them. This architecture is customary in a telecommunication system with separate user plane comprising the core network nodes and a control plane with the servers. Between the servers, the parameter sets can be transferred via the horizontal bearer independent call control (BICC) protocol. The parameter sets can then be transferred to the core network nodes and stored during connection set-up or are only sent when needed to modify a connection. Although this solution allows establishing an Iu user plane connection transparently through the core network nodes, it has the disadvantage that it requires a high amount of signaling traffic.
In the case, that inband signalling is used, two further problems can occur. Firstly, that parameter sets sent by a first RNC and a second RNC might by crossing. This happens for example, when a second RNC sends a parameter set before it receives a parameter set from the first RNC.
Secondly, an RNC might start initializations without being requested by an MSC, a so-called unsolicited initiation. To recognise said initializations, core network nodes have to monitor the user plane they transport. As this consumes processor capacity in said core network nodes, this is not always favored.